OpenEdge Getting Started:<br />Core Business Services Audit data table schema

Audit data table schema

You cannot modify the schema of the audit tables. You can add a child table to any of the audit tables (by using a foreign key relationship to a record field in the existing audit data table); however, there will be no archiving or security extended to the child table.

Figure A–1 illustrates the auditing metadata.

Figure A–1: OpenEdge Release 10.1A auditing metadata

The audit tables fall into two categories: those that hold the audit data and those that hold the audit policy configuration.

The following tables hold audit data:

_aud-audit-data

_aud-audit-data-value

The following tables hold audit policy configuration:

_aud-audit-policy

_aud-event

_aud-event-policy

_aud-field-policy

_aud-file-policy

The following tables support auditing specifically or support auditing and other functionality:

_client-session — Records additional login session information that further defines the login domain authentication system.

_db-detail — Records the binding between a database’s identity (UUID) and the encrypted MAC key used for audit data and archive integrity.

_db-option — Records the database and application options for controlling database and application operations such as auditing and security.

In addition, the existing _db table (which contains database-wide information) has been modified for auditing.

Table A–1 lists and describes all of the audit tables.

Table A–1: OpenEdge Release 10.1A audit tables
Table name	Description
`_aud-audit-data`	The actual audit data created as a result of enabled audit events according to the audit policy. All audit events, including both database and application-level audit events, are stored in this central table. However, certain fields are specific to database auditing events, and the purpose and use of some of the fields can vary depending on the type of audit event. This table schema is used for both the online audit data as well as the archive audit data. For nondatabase (create, update, delete) auditing, the fields that sequence the order of the audit data can be used for the application. For example, the sequence fields can be used to keep an ordered count of failed login attempts, or perhaps the sequence of tasks within a workflow. To avoid tampering of the data, the contents of this table can be deleted only by the registered audit data archiver. The data in this table can be sealed with a Message Digest or MAC for nonrepudiation. There are a number of indexes required on this table to facilitate efficient reporting. These indexes can be made inactive in the operational database and enabled only in an archive database, if required to improve performance of queries. Records in this table can be moved to an archive database as part of the archive process.
`_aud-audit-data-value`	A child table for the `_aud-audit-data` table; contains a record for each modified field value. A separate record is created for each modified field to make it easier to report on changes made to a specific field over time or to hold field values of large size. Whether just new values, or both old and new values, are stored is driven by the audit policy levels defined on the `_file` and `_field` tables. Values are stored in strings, and the string values are always stored in American format using the database’s code page so that they are consistent. In order to remove the dependency on the originating database, the data type and name of the field as it was at the time the value was audited is recorded in this table. This table provides for continuation records to support large data that might exceed record limits. To avoid tampering of the data, the contents of this table can be deleted only by the registered audit data archiver. The data in this table can be sealed with a Message Digest or MAC for nonrepudiation. Records in this table can be moved to an archive database as part of the archive process.
`_aud-audit-policy`	Provides a mechanism to define named audit policies that contain sets of audit configuration data according to different policy requirements, such as comprehensive auditing, standard auditing, minimum auditing, or secure auditing, for example. An audit policy controls application, database, and internal auditing settings. The use of named audit policies allows standard or template policies to be defined and deployed to target databases. As the audit policy is not tied to a particular database GUID, changes to the database GUID (for example, through dump or load, or database copies) do not impact the audit policy. It is possible to have multiple policies active; in this case, the aggregation of the policies then applies. If there are conflicts across the multiple active policies, the highest level of auditing security applies. Audit policy information is not copied to the archive database. However, modifications to the policy and information about which policies are active must be audited, and these audit entries become part of the archive.
`_aud-event`	Identifies each defined audit event and its corresponding event ID, which is a binary (integer) code used on the audit data table to save space. The event ID will also be referenced in code when creating audit data. You cannot import policies that contain events not defined in this table. Operational code does not require the details in this table, as it makes reference directly to the event ID. These details are used primarily for reporting and documentation and can also be used during the archive process to stored the archived audit data with more meaningful event names, if required. Note that this event data will be required in every database that has auditing enabled. If additional events are created, these will also have to be updated into all auditing databases. The fields used to control whether the event is enabled or not and the level of detail to capture are defined in the audit policy tables. The table facilitates the logical grouping of events by type and makes provisions for a detailed description of the event and its use in relation to auditing. This grouping mechanism can prove useful to simplify the tools used to maintain the audit functionality. OpenEdge Release 10.1A is preconfigured with standard OpenEdge-defined events that have specific event IDs; however, developers can extend the supported events as required by their application. All event IDs up to 32000 are reserved for use by OpenEdge Release 10.1A. The following event types are available: Admin — Database started or stopped. Application — Client authentication, login, logout, reauthenticate, authorization to resources, for example. Audit — Database auditing enabled or disabled; or an audit policy record created, updated, or deleted.
`_aud-event` (continued)	Data — Create, update, or delete events. Schema — Schema changes. Security — User account or authentication domain created, updated, or deleted, for example. User — User login success, user logout, or user login failed; or database user identity set or failed, for example. Utility — Database dump or load, or database table move, for example. Since OpenEdge reserves all event IDs up to 32000 for internal use, application-specific events must use an ID greater than 32000. The data in this table is copied to each database that has auditing enabled, including the archive databases.
`_aud-event-policy`	Defines the event ID and the level of detail to be recorded for those audit events used within a policy. Note that the policy is set globally for the event. Audit policy information is not copied to the archive database; however, modifications to the policy must be audited. These audit entries will be part of the archive.
`_aud-field-policy`	Defines field-level auditing configuration settings for a named audit policy. Records will exist only for fields that have specific auditing policy settings. If a record does not exist for a field, then, by default, auditing for the field is the same as what is defined for the table to which the field belongs. If no table settings are defined, auditing is, by default, disabled for the field. You can enable or disable auditing of data for specific fields and control the level of detail kept for each field for each auditable database event. Audit policy information is not copied to the archive database, but modifications to the policy must be audited. These audit entries will be part of the archive.
`_aud-file-policy`	Defines file- (table-) level auditing configuration settings for a named audit policy. Records will exist only for tables that have specific auditing policy settings. If a record does not exist for a table, then, by default, auditing is disabled for that table. You can enable or disable auditing of data for a table or its specific fields, determine what events to audit for the table, and select the level of audit detail to keep in the audit data table for the specified events. Audit policy information is not copied to the archive database, but modifications to the policy must be audited. These audit entries will be part of the archive.
`_client-session`	Records information about a client-authenticated login session. The table stores information about the client session and the methods used to authenticate the client. The table’s primary purpose is to provide additional information for auditing for the purposes of nonrepudiation—to provide extra details as to exactly who the user was. This table is part of a blank, empty database, as it has other uses beyond auditing. When used for auditing, the client session UUID will be used to associate the authenticated client session with the audit events. An authenticated client session might not always be available when recording auditing events; an example of this occurs when Progress® AppServer™ connects to a database outside of the context of an authenticated session. The data in this table can be sealed with a Message Digest or MAC for nonrepudiation. Note that the data in this table must be copied to the archive database as part of the archive process, but the contents will not be deleted as part of the same process since the client session information could be used for purposes other than auditing.
`_db`	This is the existing `_db` metaschema table for databases. Added to the table is a new field for a globally unique identifier (GUID) to uniquely identify a database and support the aggregation of audit data from multiple databases or sources. Note that the database GUID can change, for example, through backup/restore and copy operations to new databases. Therefore, give careful consideration when using it. The foreign key to related tables as joins could be broken or might need to be fixed, depending on the nature of the related data.
`_db-detail`	An extension to the `_db` database table to hold auditing-specific information. The join to `_db` is on the `_Db-guid` foreign key. The primary reason to use an additional table for the auditing information is to facilitate multiple record entries to accommodate different database GUIDs, such as when copying the contents of this table to an archive database for long-term storage where the archive database contains audit data from multiple databases, for example. Note that the join from the `_db` table is not physically shown because this data is copied with the archive process and, therefore, the record in the `_db` table might be for a different database, breaking the referential integrity. The details in this table provide a meaningful description of the database associated with a GUID and, as this is the only means to describe what the database is when the audit data contains entries for multiple databases, the contents of this table must be copied with the audit data.
`_db-detail` (continued)	Additionally, this table records the MAC key used to secure and seal the audit data. Without the MAC key, the data in the audit table cannot be validated, and so the MAC key must be copied with the audit data. If the MAC key is ever modified for a particular database, then a new database GUID must be created, since a database GUID can only have a single MAC key. It is the combination of the database GUID and the MAC key that facilitates access to sealed audit data. Also, if the database GUID ever changes, a new record must be created in this table using the current MAC key and a meaningful description of the database associated with the GUID. The contents of this table must be copied as part of the archive process, as the data is needed to describe the database and unseal the audit data. The contents, however, must not be deleted as part of the archive process, only copied to the archive database.
`_db-option`	Provides an extension to the `_db` database table for additional database options (user-defined fields). This is a generic table designed to make the `_db` metadata extensible. The use of option types up to 32000 are reserved by OpenEdge Release 10.1A for internal use. An example entry in this table would be for a database option that controls whether or not to record authenticated client sessions in the `_client-session` table.

Table A–2 through Table A–12 describe each of the audit tables individually.

Table A–2: _aud-audit-data table
Field name	Description	Data type	Format
`_Audit-data-guid`	A globally unique ID that identifies the audit data record. The ID must be globally unique to support the aggregation of audit data across multiple databases and, potentially, applications. The primary purpose of this unique ID is to provide a foreign key for the child table `_aud-audit-data-value` that is used to store individual, modified field values for database events. The value is always a 22-character, BASE-64 encoded UUID.	CHARACTER	X(28)
`_Database-connection-id`	For database connections, this is the ID that is used to track audit events for the duration of a specific database connection. This is relevant only to database create, update, and delete events.	CHARACTER	X(28)
`_Client-session-uuid`	A unique ID for the client login session; used to tie together all the audit data for a specific session. The value is always a 22-character, BASE-64 encoded UUID. For Progress AppServer sessions or connections that do not have a valid authenticated client session record in the `_aud-client-session` table, this field would refer to the UUID of the AppServer. This field is not used by either `SETUSERID( )` or the `-U` and `-P` parameters. This field is indexed together with the database connection ID field, so to obtain the details for a specific session, the database connection information must also be specified for efficiency. Multiple client sessions could occur within a single database connection.	CHARACTER	X(28)
`_User-id`	The authenticated user who has been authorized to perform a database operation or application function. This user ID can also include the domain the user was authenticated by. For example: `fred@domain` This field is copied from the `_client-session` table for ease of reference or querying and also because the use of the client session is optional.	CHARACTER	X(35)
`_Audit-date-time`	The date and time that the audit event occurred stored as `date time timezone`, which results in the time recorded to the millisecond.	DATE	99/99/9999
`_Audit-event-group`	A GUID pointing at the audit data record containing the audit event group event’s details. The value is always a 22-character, BASE-64 encoded UUID. Within an application context there can exist zero or more optional audit event groups that can carry information such as the business entity, business object, or data object. Audit event groups have starting and ending events that can be used to establish a collection of related database audit events. For example, starting an update on a ProDataSet as part of a business task might change multiple table records in multiple databases. By starting and ending an audit event group around the ProDataSet `UPDATE` operation, you can later audit all audit event records that were involved in that single application operation.	CHARACTER	X(28)
`_Audit-event-group` (continued)	Note: Audit event groups are used for auditing purposes only and do not support roll-back of data manipulation operations. The ending of an audit event group does not happen automatically, even at program exit. The application programmer must be careful to end an audit event group unless it can be assumed to include all of the audit events up to the end of the program's execution. Where an audit event group is used, its ID will point at an `_aud-audit-data` record that describes the details of the audit event group, who started it, when, etc. This field will therefore contain an `_Audit-data-guid` value as a foreign key. Starting an audit event group will create an audit data entry for the audit event group and propagate this unique ID to all connected databases with auditing enabled so they can use this in their `_Audit-event-group` field, until it is reset. This facilitates storing extra information about the audit event group without duplicating all the details onto every audit data record. Note that for the audit data record that stores the audit event group details, the `_audit-event-group` field will be blank. If any structure or subgrouping is required for audit event groups, then the `_Event-context` can be used to provide this.	CHARACTER	X(28)
`_Db-guid`	A globally unique identifier (GUID) for the database to support the aggregation of data across multiple databases. The value is always a 22-character, BASE-64 encoded UUID. This field is used in all audit-related tables to identify which database the audit information was recorded in. All other fields are then unique only within a specific database. Note that the database GUID might change, for example, through backup and restore or copy operations to new databases. Therefore, give careful consideration when using it. The foreign key to related tables as joins could be broken or might need to be fixed, depending on the nature of the related data. The other way to join from the `_db` table is through the `RECID`, which never changes but is also not globally unique; which option to use depends on the related data.	CHARACTER	X(28)
`_Transaction-id`	The database transaction ID for database events. For nondatabase events, this could be an application-supplied transaction sequence, such as a task ID. Note that transaction IDs are client-specific and are not unique in the database. The IDs can be reset and do not necessarily guarantee the order of the audit data.	INTEGER	->>>>>>>9
`_Transaction-sequence`	The sequence of updates within a transaction ID. The sequence is incremented only for auditable events so that there are no holes in the sequence. This field allows for a finer level of granularity than the audit date and time and, therefore, supports multiple updates within a millisecond while still being able to determine the order in which the updates occurred.	INTEGER	->>>>>>>9
`_Event-id`	A unique identifier for the event. This is the binary code for the event that is stored in the audit data table and referenced in code. OpenEdge Release 10.1A includes a standard set of supported event IDs, but the list can be extended by developers as required. A separate table, `_aud-event`, exists to define what the event IDs mean or are used for and whether the event is enabled through the audit policy tables.	INTEGER	->>>>>>>9
`_Event-context`	The context within which the event occurred. For application events, this could be a particular procedure or function or an action a user was authorized to access. For database create, update, or delete events, this could simply be the table name or the `database.table` name followed by a delimited list of identifying field values to identify the record that was modified. For example: `database.table + CHR(6) + field1value + CHR(7) + field2value + CHR(7) + field3value` The control code `CHR(6)` denotes the start of the identifying field value part of the context, and the `CHR(7)` is used to delimit the field values where a record is identified by more than one field. Note that the identifying fields’ values can also be stored in the child table `_aud-audit-data-value` if the value was modified and the policy is configured to audit old and new values for these fields. This field does not show old and new values because it is used to locate audit changes for a specific record in a table.	CHARACTER	X(3000)
`_Event-context` (continued)	Note that for database events, the execution context will be written as a separate record with an event name of `pvm.appcontext`. This is to avoid repeating the execution context on every audit record, writing new context details only when the execution context changes. The field `_Application-context-id` points to the record that contains the actual context. See Table A–5 for more details.
`_Application-context-id`	The application context of an audit log entry is stored in a separate `_aud-audit-data` record with full details of the context, such as when it was created or by whom, for example. A special event ID is used to identify context records. The content of the context data is user-defined, and the current context is set and reset using audit context 4GL statements. The context record is stored in the database pointed at by the `AUDIT-DB` alias. The key to the context record is then propagated to all connected databases that have auditing enabled, and this key is written into this field as a foreign key reference to the full context data, until it is reset.	CHARACTER	X(28)
`_Application-context-id` (continued)	This avoids duplicating large amounts of context data on every audit data record, yet still provides an efficient way to retrieve the context from the separate context record. Note that the record that contains the details of the context data will be in the databases that have the context event ID enabled.
`_Event-detail`	The detail for the event. The detail can be a stream of field values that are set to be recorded in compressed field-value mode. For database events, this would be blank, as the details of what changed are stored in the child table `_aud-audit-data-value` with a record for each modified field value. For application events, its use is user-defined.	CHARACTER	X(3000)
`_Audit-custom-detail`	A custom field provided to support additional audit data required by an application.	CHARACTER	X(3000)
`_Audit-data-security-level`	This field is copied from the `_Audit-data-security-level` field on the `_aud-audit-policy` table and records the data security level used for this record. The value of this field determines what information is written to the `_Data-seal` field at creation time as follows: 0 — No additional security applied to audit data. 1 — Stores a message digest in the `_Data-seal` field of the audit data tables to guarantee the integrity of the data. 2 — Stores a MAC in the `_Data-seal` field of the audit data tables to guarantee the integrity of the data. A MAC is more secure than a message digest. The MAC key to use is stored in the associated field `_Audit-mac-key`. The field value is used when validating audit record seals to indicate what validation method to use.	INTEGER	->9
`_Data-seal`	An internally generated data integrity seal on the data. The seal guarantees the integrity of the data and ensures it has not been tampered with outside of the registered services permitted to maintain this data. This could be a message digest or a MAC, depending on the policy’s security level at the time of creation. The use of the data seal is optional. It guarantees nonrepudiation of the data but will have a cost of additional storage space and a possible impact on performance to assign a value and check the results.	CHARACTER	X(28)

Table A–3: _aud-audit-data-value table
Field name	Description	Data type	Format
_`Audit-data-guid`	A globally unique ID that identifies the audit data record. The value is always a 22-character, BASE-64 encoded UUID. The ID must be globally unique to support the aggregation of audit data across multiple databases and, potentially, applications. The primary purpose of this unique ID is to provide a foreign key for the child table `_aud-audit-data-value` that is used to store individual, modified field values for database events.	CHARACTER	X(28)
`_Field-name`	The actual name of the field the audit value is for, such as `customerName`, for example.	CHARACTER	X(32)
`_Continuation-sequence`	The continuation sequence facilitates breaking a single audit record value into multiple parts to avoid breaking record limits where the audit data value is too large to fit into a single record. A possible reason for this is because the field name, old value, and new value are being stored; and one of the values itself could, in fact, exceed the record limit of 32K.	INTEGER	->9
`_Data-type-code`	Contains an integer code for the data type of the audit value where the audit value is stored as a string. A code for the data type is used to minimize the storage impact of recording this information. The primary reason for recording the data type of the audit value is to guard against schema changes, that is, to cater for data type changes, and to remove the dependency on the originating database to determine the data type of the value. The data type is required for reporting in order to display the value in the appropriate format, as the actual value is stored as a character string in a consistent format (American). The value must be cast to the originating native data type in order to deal with internationalization formatting issues.	INTEGER	->9
`_Data-type-code` (continued)	Sample data type codes are: 1 — Character 2 — Date 3 — Logical 4 — Integer 5 — Decimal 7 — Recid 8 — Raw 11— Memptr 13 — Rowid 18 — Blob 19 — Clob 34 — Datetime 39 — Longchar 40 — Datetime-TZ	INTEGER	->9
`_Old-string-value`	If the field can be represented as a string value, then this field contains the old string value of the modified field. This value is in American format for consistency.	CHARACTER	X(3000)
`_New-string-value`	If the field can be represented as a string value, then this field contains the new string value of the modified field. This value is in American format for consistency.	CHARACTER	X(3000)
`_Audit-data-security-level`	This field is copied from the `_Audit-data-security-level` field on the `_aud-audit-policy` table and records the data security level used for this record at the time the record was created. The value of this field determines what information is written to the `_Data-sea`l field: 0 — No additional security applied to audit data. 1 — Stores a message digest in the `_Data-seal` field of the audit data tables to guarantee the integrity of the data. 2 -— Stores a MAC in the `_Data-seal` field of the audit data tables to guarantee the integrity of the data. A MAC is more secure than a message digest. The MAC key to use is stored in the associated field `_Audit-mac-key`.	INTEGER	->9
`_Data-seal`	An internally generated data integrity seal on the data that guarantees the integrity of the data and ensures it has not been tampered with outside of the registered services permitted to maintain this data. This could be a message digest or a MAC. The use of the data seal is optional, as it guarantees nonrepudiation of the data but will have a cost of additional storage space and a possible impact on performance to assign a value or check the results.	CHARACTER	X(28)

Table A–4: _aud-audit-policy table
Field name	Description	Data type	Format
`_Audit-policy-guid`	A globally unique ID used to identify the audit policy. The value is always a 22-character, BASE-64 encoded UUID. The ID is used as the foreign key on policy-related tables. The use of a unique ID for the foreign key facilitates changes to the audit policy details, such as the name.	CHARACTER	X(28)
`_Audit-policy-name`	A unique name used to identify the audit policy. As the name is not used as a foreign key to related tables, changes to the policy name are permitted.	CHARACTER	X(35)
`_Audit-policy-description`	A free text description used to describe the purpose or use of the audit policy.	CHARACTER	X(70)
`_Audit-data-security-level`	A database-wide field that controls the level of security applied to the audit data transaction tables `_client-session`, `_aud-audit-data`, and `_aud-audit-data-value`, each of which has a field called `_Data-seal`. The setting of this field determines what information is written to the `_Data-seal` field, as follows: 0 — No additional security applied to audit data. 1 — Stores a message digest in the `_Data-seal` field of the audit data tables to guarantee the integrity of the data.	INTEGER	->9
`_Audit-data-security-level` (continued)	2 — Stores a MAC in the `_Data-seal` field of the audit data tables to guarantee the integrity of the data. A MAC is more secure than a message digest. The MAC key to use is stored in the associated field `_Audit-mac-key`. If this field value is ever changed, it will impact how the audit data is sealed or unsealed; therefore, the value must be recorded along with the `_data-seal` in each table that is sealable.	INTEGER	->9
`_Audit-custom-detail-level`	Applicable only to application-audit events (not database tables and fields); controls whether to record the value in the `_Audit-custom-detail` field on the `_aud-audit-data` record, as follows: 0 / OFF — Ignores audit custom detail parameter. 1 /ON — Records passed-in audit custom detail value in the `_Audit-custom-detail` field. Note that within a single database with multiple active policies, multiple custom detail levels can be active, as each policy can have a different custom detail level. The custom detail level to use in each case will be the maximum value that applies.	INTEGER	->9
`_Audit-policy-active`	A flag (set to NO by default) that determines which audit policies are active for the current database. It is possible to have multiple policies active, and the aggregation of the policies then applies. If there are conflicts across the multiple active policies, then the highest level will apply. Changing which policies are active is an auditable event.	LOGICAL	YES/NO

Table A–5: _aud-event table
Field name	Description	Data type	Format
`_Event-id`	A unique identifier for the event. This is the binary code for the event that is stored in the audit data table and referenced in code. OpenEdge Release 10.1A ships with a standard set of event IDs supported, but the list can be extended by developers as required. OpenEdge Release 10.1A reserves all event IDs up to 32000.	INTEGER	->>>>>9
`_Event-type`	This is the type of audit event used to categorize the events for tools and reporting purposes. This field has no meaning in operational code. The following event types are available: Admin — Database started or stopped. Application — Client authentication, login, logout, reauthenticate, authorization to resources, for example. Audit — Database auditing enabled or disabled; or an audit policy record created, updated, or deleted. Data — Creates, updates, or deletes events. Schema — Schema changes. Security — User account or authentication domain created, updated, or deleted, for example. User — User login success, user logout, or user login failed; or database user identity set or failed, for example. Utility — Database dump or load, or database table move, for example.	CHARACTER	X(15)
`_Event-type`		CHARACTER	X(15)
`_Event-name`	This is a meaningful name for the event within the context of the event type. The event type and the event name together describe the event and ideally should be unique.	CHARACTER	X(35)
`_Event-description`	This is a free text description of the event used to explain the purpose of the audit event with sample use cases, etc.	CHARACTER	X(500)

Table A–6: _aud-event-policy table
Field name	Description	Data type	Format
`_Audit-policy-guid`	This is a globally unique ID used to identify the audit policy. The value is always a 22-character, BASE-64 encoded UUID. The GUID is used as the foreign key on policy-related tables. The use of a unique ID for the foreign key facilitates changes to the audit policy details, such as the name.	CHARACTER	X(28)
`_Event-id`	A unique identifier for the event. This is the binary code for the event that is stored in the audit data table and referenced in code. OpenEdge Release 10.1A ships with a standard set of event IDs supported, but the list can be extended by developers as required. OpenEdge Release 10.1A reserves all event IDs up to 32000.	INTEGER	->>>>>9
`_Event-level`	This field controls whether auditing for this event is enabled or not, and, if auditing is enabled, the level of detail to capture for the event. The supported values are as follows: 0 — Auditing off for this event (default). 1 — Auditing on for this event; records minimum details. 2 — Auditing on for this event; records full details. If this field has a value greater than 0, then auditing is enabled for this event. The meaning of minimum or full details is dependent on the type and nature of the event. For example, for a database connection event, minimum details could simply record that the connection was made and by whom, whereas full details could include the physical connection parameters used. The use of full details is optional and might not always be relevant to all event types.	INTEGER	->9

Table A–7: _aud-field-policy table
Field name	Description	Data type	Format
`_Audit-policy-guid`	This is a globally unique ID used to identify the audit policy. The value is always a 22-character, BASE-64 encoded UUID. The ID is used as the foreign key on policy-related tables. The use of a unique ID for the foreign key facilitates changes to the audit policy details, such as the name.	CHARACTER	X(28)
`_File-Name`	This is the actual table name of the database table that the audit policy settings are for.	CHARACTER	X(32)
`_Owner`	The schema owner for the table, such as PUB, for example. SQL allows for the same table in different schemas.	CHARACTER	X(32)
`_Field-Name`	This is the actual field name of the database field that the audit policy settings are for.	CHARACTER	X(32)
`_Audit-create-level`	This field defines the level of auditing active for this specific field during a create event. If create auditing is turned off at the table level (the `_Audit-create-level` in the `_aud-file-policy` table is set to 0), then this field is ignored, as shown: –1 — Turns create auditing off for this field. Do not record any record-change events or field values. 0 — Uses the audit level setting as defined by the `_Audit-create-level` in the `_aud-file-policy` table; do not override it at the field level. This is the default. 1 — Min Audit Data. Stores only when the audit event occurred and who caused the event but does not store additional details for the initial values. 2 — Standard Audit Data. Same as 1 but additionally stores the initial values in the audit data. 12 —Records both record-change events and field values in default (streaming) mode, if possible. When create auditing is done, audit data would typically not include values, as these would simply indicate the initial values. For creates, an update event would also occur where the values could be recorded.	INTEGER	->9
`_Audit-update-level`	This field defines the level of auditing active for this specific field during an update event. If update auditing is turned off at the table level (`_Audit-update-level` in the `_aud-file-policy` table is set to 0), then this field is ignored, as shown: –1 — Turns off update auditing for this field. Does not record any record-change events or field values. 0 — Uses the audit level setting as defined by the `_Audit-update-level` in the `_aud-file-policy` table; does not override it at the field level. This is the default. 1 — Min Audit Data. Stores only when the audit event occurred and who caused the event but does not store additional detail for the before and after values of this field.	INTEGER	->9
`_Audit-update-level` (continued)	2 — Standard Audit Data. Same as 1 but additionally stores the new value in the audit data where applicable. In order to compare old and new values, previous records must be read to determine the old value and rely on the correct sequence of the audit events in the audit data table. This cannot always be guaranteed. Note that only modified data is kept in the audit data table, so many records might need to be read to get to the old value for a specific field. 3 — Full Audit Data. This is the same as 2 but additionally stores both the old and new values in the audit data table. This makes it easier to query or compare old and new values but requires additional storage space for the audit data. 12 —Records both record-change events and the new value of only the changed fields in default (streaming) mode, if possible. 13 — Records both record-change events and the new and old values of only the changed fields in the default (streamed) mode, if possible.	INTEGER	->9
`_Audit-delete-level`	This field defines the level of auditing active for this specific field during a delete event. If delete auditing is turned off at the table level (the `_Audit-delete-level` in the `_aud-file-policy` table is set to 0), then this field is ignored, as shown: –1 — Turns off delete auditing for this field. Does not record any record-change events or field values. 0 — Uses the audit level setting as defined by the `_Audit-delete-level` in the `_aud-file-policy` table; does not override it at the field level. This is the default. 1 — Min Audit Data. Stores only when the audit event occurred and who caused the event but does not store additional details for the final field value. 2 — Standard Audit Data. Same as 1 but additionally stores the final field value in the audit data to record the final state of the record prior to deletion. 12 — Records both record-change events and field values in default (streamed) mode, if possible.	INTEGER	->9
`_Audit-identifying-field`	This identifies a field as being an identifying field that would be used to find a unique record in the table. It is an integer to support multiple identifying fields in a specified sequence. Typically, this would be the fields that make up the primary index on the table, but it could be something else. Therefore, it is configurable. Fields that are made identifying fields by specifying a value greater than 0 are then stored in the `_event-context` on the audit data table to determine which record actually changed. If no fields are marked as identifying fields, then the fields in the primary index would be used by default.	INTEGER	->9

Table A–8: _aud-file-policy table
Field name	Description	Data type	Format
`_Audit-policy-guid`	A globally unique ID used to identify the audit policy. The value is always a 22-character, BASE-64 encoded UUID. The ID is used as the foreign key on policy-related tables. The use of a unique ID for the foreign key facilitates changes to the audit policy details, such as the name.	CHARACTER	X(28)
_`File-Name`	The actual name of the database table that the audit policy settings are for.	CHARACTER	X(32)
`_Owner`	The schema owner for the table, such as PUB, for example. SQL allows for the same table in different schemas.	CHARACTER	X(32)
`_Audit-create-leve`l	The default level of auditing active for the table for create events. The level can have one of the following values: 0 — Auditing is off for this table for create events. This is the default. If this field is 0 at the table level, then any more specific audit settings on the `_aud-field-policy` table are ignored. 1 — Min Audit Data. Stores only when the audit create event occurred and who caused the event but does not store additional details for the initial values. 2 — Standard Audit Data. Same as 1 but additionally stores the initial values in the audit data. 12 — Records both record-change events and field values in default (streamed) mode, if possible. If auditing is enabled by specifying an audit level greater than 0, then the level of detail recorded can be overridden at the field level using `_Audit-create-level` set on each `_aud-field-policy` record.	INTEGER	->9
`_Audit-update-level`	Defines the default level of auditing active for the table for update events. The level can have one of the following values: 0 — Auditing is off for this table for update events. This is the default. If this field is 0 at the table level, then any more specific audit settings on the `_aud-field-policy` table are ignored. 1 — Min Audit Data. Stores only when the audit update event occurred and who caused the event but does not store additional details for the before and after values. 2 -— Standard Audit Data. Same as 1 but additionally stores the new value in the audit data where applicable. In order to compare old and new values, previous records must be read to determine the old value and rely on the correct sequence of the audit events in the audit data table. This cannot always be guaranteed. Note that only modified data is kept in the audit data table, so many records might need to be read to get to the old value for a specific field.	INTEGER	->9
`_Audit-update-level` (continued)	3 — Full Audit Data. This is the same as 2 but additionally stores both the old and new values in the audit data table. This makes it easier to query or compare old and new values but requires additional storage space for the audit data. 12 — Records both record-change events and the new value of only the changed fields in default (streamed) mode, if possible. 13 — Records both record-change events and the new and old values of only the changed fields in default (streamed) mode, if possible. If auditing is enabled by specifying an audit level greater than 0, then whether an audit record is created in the audit data table is further controlled by the `_Audit-update-level` on the `_aud-field-policy` records.	–	–
`_Audit-delete-level`	Defines the default level of auditing active for the table for delete events. The level can have one of the following values: 0 — Auditing is off for this table for delete events. This is the default. If this field is 0 at the table level, then any more specific audit settings on the `_aud-field-policy` table are ignored. 1 — Min Audit Data. Stores only when the audit delete event occurred and who caused the event but does not store additional details for the actual values. 2 — Standard Audit Data. Same as 1 but additionally stores the current values in the audit data to record the final state of the record before it was deleted. 12 — Records both record-change events and field values in default (streamed) mode, if possible. If auditing is enabled by specifying an audit level greater than 0, the level of detail recorded can be overridden at the field level using `_Audit-delete-level` set on each `_aud-field-policy` record.	INTEGER	->9
`_Create-event-id`	The event ID to use for record creates for this table. The default is 5100 for normal record creates, but this can be set to a different value for grouping of related create events across multiple tables. For example, the create event ID could be directed to a specific event ID for creation of orders for all the tables related to order creation, such as order, order line, or stock tables, for example. This would make it easier to then query the audit data by event ID and report on all the data related to the order creation. This concept is used for internal system events to group things like schema changes, audit policy changes, or security permission changes, for example. Note: It is invalid to have multiple active audit policies with the same table defined with conflicting event IDs.	INTEGER	->>>>>9
`_Update-event-id`	The event ID to use for record updates for this table. The default is 5101 for normal record updates, but the ID can be set to a different value for grouping of related update events across multiple tables. For example, the update event ID could be directed to a specific event ID for update of orders for all the tables related to order updates, such as order, order line, or stock tables, for example. This would make it easier to then query the audit data by event ID and report on all the data related to the order update. This concept is used for internal system events to group things like schema changes, audit policy changes, or security permission changes, for example. Note: It is invalid to have multiple active audit policies with the same table defined with conflicting event IDs.	INTEGER	->>>>>9
`_Delete-event-id`	The event ID to use for record deletes for this table. The default is 5102 for normal record deletes, but the ID can be set to a different value for grouping of related delete events across multiple tables. For example, the delete event ID could be directed to a specific event ID for deletion of orders for all the tables related to order deletion, such as order, order line, or stock tables, for example. This would make it easier to then query the audit data by event ID and report on all the data related to the order deletion. This concept is used for internal system events to group things like schema changes, audit policy changes, or security permission changes, for example. Note: It is invalid to have multiple active audit policies with the same table defined with conflicting event IDs.	INTEGER	->>>>>9

Table A–9: _client-session table
Field name	Description	Data type	Format
`_Client-session-uuid`	A unique ID for the client login session and for when auditing is used to tie together all the audit data for a specific session. The value is always a 22-character, BASE-64 encoded UUID.	CHARACTER	X(28)
`_Client-name`	The name of the type of client session; for example: AS — Appserver WS — WebSpeed 4GL — 4GL Client SQL — SQL Client DBA — Database Admin Tools	CHARACTER	X(35)
`_User-id`	The ID of the authenticated user.	CHARACTER	X(35)
`_Authentication-date-time`	The authentication date, time, and time zone.	DATE	99/99/9999
`_Server-uuid`	The unique ID for the connected server, such as Progress AppServer or Progress® WebSpeed® server, to determine exactly which server was used when multiple servers are in operation.	CHARACTER	X(28)
`_Authentication-domain-type`	The type of authentication plug-in used, such as LDAP, for example.	CHARACTER	X(35)
`_Authentication-domain-name`	The application alias or logical name depending on the domain type or authentication plug-in being used; for example, for LDAP this would be an LDAP domain such as App1LDAP.	CHARACTER	X(70)
`_Db-guid`	A globally unique identifier (GUID) for the database where the authenticated client session was begun or originated. The value is always a 22-character, BASE-64 encoded UUID.	CHARACTER	X(28)
`_Session-custom-detail`	User-defined session information, such as terminal ID, provided in free text.	CHARACTER	X(3000)
`_Audit-data-security-level`	Records the data security level used for this record. This field is copied from the `_Audit-data-security-level` field on the `_aud-audit-policy` table. The value of this field determines what information is written to the `_Data-seal` field, as follows: 0 — No additional security applied to audit data. 1 — Stores a message digest in the `_Data-seal` field of the audit data tables to guarantee the integrity of the data. 2 — Stores a MAC in the `_Data-seal` field of the audit data tables to guarantee the integrity of the data. A MAC is more secure than a message digest. The MAC key to use is stored in the associated field `_Audit-mac-key`.	INTEGER	->9
`_Data-seal`	An internally generated seal on the data that guarantees the integrity of the data and ensures it has not been tampered with outside of the registered services permitted to maintain this data. This could be a message digest or a MAC. The use of the data seal is optional, as it guarantees nonrepudiation of the data but will have a cost of additional storage space and a possible impact on performance to assign a value or check the results.	CHARACTER	X(28)

Table A–10: _db table
Field name	Description	Data type	Format
`_Db-guid`	The current globally unique identifier (GUID) for the database to support the aggregation of data across multiple databases. The value is always a 22-character, BASE-64 encoded UUID. This field is used in all audit-related tables to identify the database for which the audit information exists. All other fields are then unique only within a specific database. Note that the database GUID can change, for example, through backup and restore or copy operations to new databases. Therefore, give careful consideration when using it. The foreign key to related tables as joins could be broken or might need to be fixed, depending on the nature of the related data. The other way to join from the `_db` table is through the `RECID`, which never changes but is also not globally unique; which option to use depends on the related data.	CHARACTER	X(28)

Table A–11: _db-detail table
Field name	Description	Data type	Format
`_Db-guid`	A globally unique identifier (GUID) for the database to support the aggregation of data across multiple databases. The value is always a 22-character, BASE-64 encoded UUID. This field is used in all audit-related tables to identify the database for which the audit information exists. All other fields are then unique only within a specific database. Note that the database GUID can change, for example, through backup and restore and copy operations to new databases. Therefore, give careful consideration when using it. The foreign key to related tables as joins could be broken or might need to be fixed, depending on the nature of the related data. The other way to join from the `_db` table is through the `RECID`, which never changes but is also not globally unique; which option to use depends on the related data.	CHARACTER	X(28)
`_Db-description`	A meaningful description of the database associated with the current database GUID, used to describe the GUID where data is aggregated for multiple databases. The database physical name can be used to describe the database. If the database GUID ever changes, a new record will always be created in this table and the description must be reapplied to the new GUID.	CHARACTER	X(70)
`_Db-mac-key`	If the `_Audit-data-security-level` is set to 2 indicating that the security data is sealed using a MAC, then this field defines the MAC key to use. If the `_Audit-data-security-level` is not set to 2, then this field will be ignored. Without the MAC key, the data in the audit table cannot be used; therefore, the MAC key must be copied with the audit data. If the MAC key is ever modified for a particular database, then a new database GUID must be created since a database GUID can only have a single MAC key. It is the combination of the database GUID and the MAC key that facilitates access to sealed audit data. Also, if the database GUID ever changes, a new record must be created in this table with the current MAC key and a meaningful description of the database associated with the GUID. Note: The MAC key must be stored as an encrypted raw value for security purposes, as it has characteristics similar to a password.	RAW
`_Db-custom-detail`	A free-text field that provides additional custom information for a database specific to auditing; the detail will also be copied with the audit data as part of the archive process. Note: When the database GUID changes, a new record will be created in this table and the custom detail must be reapplied to the new record.	CHARACTER	X(3000)

Table A–12: _db-option table
Field name	Description	Data type	Format
`_Db-recid`	The `RECID` of the `_db` table to identify the database for which these options exist. The `RECID`, rather than the database GUID, is used because the `RECID` never changes for a database. This information is specific to a single database and has no meaning outside of a database.	INTEGER	->>>>>>>9
`_Db-option-type`	The type of option (for example, security, auditing, or context) used to group related options together. OpenEdge reserves the first 32000 option types.	INTEGER	->>>>>9
_`Db-option-code`	A code within the option type to identify a specific option, such as `recauthsession`, to decide whether to record authentication sessions (yes or no), for example.	CHARACTER	X(35)
`_Db-option-description`	A free-text description of the database option.	CHARACTER	X(500)
`_Db-option-value`	The value of the database option; for example, for the option to record authenticated sessions, the value would be yes or no. This is a character field.	CHARACTER	X(70)